Every time CISA adds a new ICS advisory to the Known Exploited Vulnerabilities catalog, somewhere a plant IT lead forwards it to a controls engineer with a subject line like “URGENT – need this patched.” And every time, the controls engineer writes back something like: that PLC runs a continuous process, the vendor hasn’t validated this firmware version against our application, and the next maintenance window is in four months. Both people are right. That’s the problem.
The KEV catalog was built for a world where patching is a scheduling problem. In OT, patching a PLC or HMI is frequently an engineering-change problem — one that touches validated control logic, safety interlocks, vendor support agreements, and sometimes regulatory qualification of the process itself. Borrowing an IT patch SLA and slapping it onto a programmable logic controller doesn’t make the plant safer. It just guarantees you miss the deadline, on paper, forever.
The fix isn’t to ignore CISA advisories until the next planned downtime. It’s to replace “patch by date X” with a documented, defensible risk-treatment decision — one that a cyber insurance underwriter or an OEM customer auditing your supply chain can actually read and accept.
Why the IT patch clock doesn’t transfer to the plant floor
IT vulnerability management assumes you can patch, reboot, and validate in a maintenance window measured in hours, on infrastructure that’s largely redundant. OT doesn’t work that way. A PLC controlling a continuous process, a packaging line running three shifts, or an HMI tied to a safety system typically can’t be taken offline without a production impact that has to be scheduled, sometimes months out, sometimes coordinated with a customer’s own shutdown calendar.
On top of that, many controllers and HMIs in the field are running firmware or OS versions the OEM no longer actively patches, or patches exist but require the vendor (or a certified integrator) to revalidate the application logic afterward. A firmware update that’s routine on a lab bench can invalidate a safety case or void a warranty on the floor. None of this is an excuse to do nothing — but it’s the reason a fixed SLA borrowed from IT collapses on contact with reality.
Triage by exploitability and exposure, not by CVSS score alone
The KEV catalog’s whole value proposition is that it tells you which vulnerabilities are being actively exploited in the wild, as opposed to the much larger universe of vulnerabilities that are merely severe on paper. That’s the right starting filter. From there, triage every KEV-listed ICS advisory against three questions before you decide anything about timing:
- Is the affected device actually reachable from a path an attacker could use? A PLC sitting behind a properly configured industrial DMZ with no direct internet path and no engineering workstation dual-homed to the corporate network is a fundamentally different risk than the same PLC on a flat network with a vendor remote-access tool installed.
- Does exploitation require network access, local access, or physical access? Many ICS advisories require an attacker already be on the OT network segment, which changes the calculus considerably if your segmentation is real and enforced, not just diagrammed.
- What’s the actual consequence if it’s exploited — denial of a single line, or something that touches safety, quality release, or a regulated process? This is where you loop in process safety and quality, not just IT security.
This is standard risk-based vulnerability management, and it maps cleanly onto the zone-and-conduit thinking in IEC 62443. The KEV listing tells you urgency in the abstract. Your network architecture and segmentation tells you urgency in your plant.
Compensating controls: the part auditors actually want to see
Insurers and OEM customers increasingly aren’t asking “did you patch.” They’re asking “show me your process for handling vulnerabilities you can’t immediately patch, and show me it was followed.” That distinction is your entire strategy. Three compensating controls do most of the real work:
Segmentation and zone enforcement
If the vulnerable PLC sits in a properly isolated Purdue-model zone with an enforced industrial firewall between it and anything routable, document exactly what traffic is permitted, what’s blocked, and when that ruleset was last verified. “We have a DMZ” is not evidence. A current firewall rule export, a network diagram with the vulnerable asset marked, and a recent segmentation test are evidence.
Virtual patching at the DMZ or firewall
Where the KEV entry describes a specific exploit signature or attack pattern — a malformed protocol request, a known exploit path over a particular port — an intrusion prevention rule or deep packet inspection policy at the industrial firewall can block that specific technique without touching the PLC at all. This is genuinely the closest thing OT has to a real substitute for patching on schedule, and it’s worth investing in a firewall platform that supports ICS-aware IPS signatures for exactly this reason. Document the rule, the date it was deployed, and what it’s intended to block.
Engineering workstation and remote access hardening
A huge share of real-world ICS compromises don’t come through the PLC’s own network interface — they come through the engineering workstation used to program it, or through vendor remote access. Application allowlisting on EWS machines, removing persistent internet access from anything with programming software installed, and requiring MFA plus session logging on any remote vendor access channel closes off the path attackers actually use, independent of whether the PLC itself has an unpatched CVE.
Writing the risk acceptance so it survives scrutiny
A risk acceptance memo that says “will patch when convenient” will get rejected by any competent underwriter or auditor, and it should be. One that will hold up has a specific shape:
- The CVE and KEV listing date, with a plain-language description of what the vulnerability actually allows.
- The exposure assessment — reachability, access requirements, consequence — tied to your actual network documentation, not a generic statement.
- The specific compensating controls in place, with dates and evidence, not intentions.
- A firm remediation date tied to a real event — the fall shutdown, the next validated firmware release, the scheduled line rebuild — not “TBD” or “ongoing.”
- Named ownership: who accepted the risk, who reviews it, and when it gets reassessed if the threat picture changes (for instance, if CISA updates the advisory or exploitation activity increases).
That last point matters more than people think. A risk acceptance isn’t a one-time document you file and forget — it’s a living record that needs a review cadence, because a KEV entry that was low-exposure in January can become urgent in June if your network topology changes or a new exploit tool starts circulating.
The real shift this requires
None of this is about finding a clever way to avoid patching. Patch when you legitimately can — during the next validated maintenance window, with vendor sign-off, tested first on a non-production asset if you have one. The point of this framework is that between “KEV listed it” and “we patched it,” there’s a defensible middle state, and manufacturers need to get comfortable documenting that state formally instead of leaving it as an informal understanding between the plant manager and the controls team.
Insurers and OEM customers asking for remediation timelines aren’t looking for zero unpatched CVEs — anyone who’s spent time on a real plant floor knows that bar is unrealistic. They’re looking for evidence that you know what you have, know what’s actually exposed, and have real controls doing real work while you wait for the window that lets you fix it properly. Build that evidence trail before someone asks for it, not after.
This article was written with the assistance of artificial intelligence. While we aim for accuracy, the information may be incomplete, out of date, or incorrect, and should be independently verified before you rely on it for any decision. It is provided for general information only and does not constitute professional advice.
